Finished the BASIC intro in the graphics chapters #542
Conversation
| @@ -297,7 +295,7 @@ \subsection*{VIC IV organization and memory access basics} | |||
|
|
|||
| The system can have up to 16 banks and certain banks also have certain tasks. Banks 0 and 1 are RAM, which means you can read and write to them, while banks 2 and 3 are ROM and not so easy to override. | |||
|
|
|||
| Bank 0 (from the perspective of the BASIC 65 operating system that runs when you power the system on) is called the system bank. It contains regions such as: | |||
| Bank 0 (from the perspective of the BASIC65 operating system that runs when you power the system on) is called the system bank. It contains regions such as: | |||
There was a problem hiding this comment.
I don't agree with this style change. We need to do a comprehensive style review for the entire doc set and build out the style guide. I would advocate for "BASIC 65" when we do that.
| \end{screenoutput} | ||
|
|
||
| As you have seen in the illustration on the page before, the VIC chip divides the memory into 4 video banks of 16KB each. It is important to understand that you do not use a register of the VIC to define the video bank inside the (memory-)bank 0, instead you use the data bits 0 and 1 of \$DD00 or 56576 decimal. This used to be a register of the CIA-2 chip on the Commodore 64 but in your MEGA65 it is implemented as a virtual register. The "preparation" needed to set the video bank happens in line 30 while in the following line the video bank itself is set. By the way, when you convert the decimal value 3 (line 30) into its binary format, it is 00000011 and proves: the data bits 0 and 1 are set to 1, so reading and writing is activated. | ||
| As you have seen in the illustration on the page before, the VIC chip divides the memory into 4 video banks of 16KB each. |
There was a problem hiding this comment.
Try to preserve whitespace layout of the source so it's easier to find the actual changes in the pull request. (We should decide whether to prefer single-line paragraphs vs. hard-wrapped paragraphs, but regardless of what we decide we should make that change comprehensively in a single change without other changes.)
| set these two locations: | ||
|
|
||
| \begin{screenoutput} | ||
| 50 POKE $D018, PEEK($D018) AND 247 OR 0 :REM BITMAP DATA STARTS AT $0000 |
There was a problem hiding this comment.
This should use a realistic example of where a program might keep bitmap graphics data. As the text says later, locating bitmap data at $0000 is never a good idea.
I assume that this is trying to avoid a discussion of memory banking and using BANK 128, which leaves no room in bank 0 for bitmap graphics data. It would be better to design a realistic example with an appropriate BANK statement, then refer to the Memory chapter for an explanation.
It could be argued that there is no realistic BASIC example that does bitmap graphics this way. I have mixed feelings about providing BASIC examples that illustrate a point but aren't realistic techniques. I like that BASIC requires no third-party tools and can be typed immediately by the reader. Maybe we just need to state clearly and up front when we're providing an experiment that demonstrates registers that isn't a realistic technique for programs. Alternatively, we can prepare the reader for assembly language early in the book, then use assembly language for examples throughout the book. It's a larger organizational question and I'll have to think about it some more.
For now I'll let you decide whether to write a different example that demonstrates a more useful memory range vs. rewriting the text to say "you'd never do this in a real program, but just as a demonstration..." We can resolve the larger question about assmebly language examples in rewrites later.
| and storing graphic data there is not really clever. You see, we have to make a lot of compromises and face many challenges when we don't use BASIC's built-in graphics commands, | ||
| but work directly in memory to generate graphics. | ||
|
|
||
| \subsection*{From BASIC to machine code} |
There was a problem hiding this comment.
Probably remove this for now. I suspect that a chapter on graphics in general (i.e. not specific to BASIC graphics commands) will be mostly register and memory manipulation, in which case the differences between PEEK/POKE and lda/sta don't justify extra material. We should think about how we want to include memory mapping in this discussion.
(I intend to cover the BASIC graphics subsystems in a separate chapter and probably a separate book. If you want to contribute to that let me know, but I think that material should be separate from this chapter, because it's probably a best practice to not mix BASIC graphics commands and direct register manipulation.)
There was a problem hiding this comment.
Yeah ! Thanks for this valuable feedback, I will think about it, maybe i should skip that BASIC starter. Let me think about it. :-)
Please check my english, i am not a native ....